Telecommunications systems have historically provided redundant load carrying capacity by maintaining multiple units at certain points within the network system. These multiple units have often been configured such that one unit operates as an active unit and the second unit operates as an active standby unit. The active unit and the active standby unit (hereinafter, standby unit) have traditionally been provisioned identically. The active unit traditionally carries the primary load and the standby unit becomes available to carry the load in the event the active unit fails or is taken off line for any reason.
The transition of the load from the active unit to the standby unit has historically created many problems with a loss of active calls. There is also a large amount of overhead associated with a load switch from the active to the standby unit. This overhead is in the form of inter-unit and intra-system messaging and communication. In order to minimize the impact of a load transition, the active unit periodically forwards updates of primary active load information to the standby unit. In this way, the standby unit is maintained in a ready state, prepared to carry the load of the active unit at any moment with minimal load loss.
For example, as shown in FIG. 1, a telecommunications subsystem 100 is shown. Within telecommunications subsystem 100 is a SIP entity 101 having an active SIP host 102 and standby SIP host 104. Active SIP host 102 and standby SIP host 104 are connected to each other through Internet protocol (IP) network 106. Also connected to IP network 106 are media gateway/media gateway controller (MG/MGC) 108 and MG/MGC 110.
Each MG/MGC 108 and MG/MGC 110 may maintain state information for SIP dialogs for calls in progress or being initiated to or from subscriber terminals 112 and 114 that are connected to each MG/MGC. According to IETF RFC 3261, a SIP dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages between the user agents and proper routing of requests between both of them. The dialog represents a context in which to interpret SIP messages. Since each MG/MGC may maintain many dialogs, for example, thousands or tens of thousands of dialogs, switching from an active host to a standby host may require multiple messages to be sent to peer SIP entities.
In one implementation, if active SIP host 102 were to fail and standby SIP host 104 were to attempt to transition the load from active SIP host 102, the following message sequence for each dialog maintained by each SIP peer would be required. In order for each dialog maintained by MG/MGC 108 to have the proper IP address of the standby SIP host 104 associated with it, the standby SIP host 104 would need to send an INVITE message 116 to MG/MGC 108 for each dialog associated between MG/MGC 108 and active SIP host 102. For each INVITE message, MG/MGC 108 would send a 200 OK message 118 to standby SIP host 104. Standby SIP host 104 would then respond with an acknowledgement (ACK) message 120 for each SIP dialog.
As discussed above, each MGC may maintain thousands of dialogs. With the above described message sequence of INVITE message 116, 200 OK message 118 and ACK message 120, this correlates to thousands of messages for each MGC for every switchover event from active SIP host 102 to standby host 104. This overhead may result in lost calls due to the time required to send this many messages while attempting to transition all of the dialogs to the IP address of the new standby SIP host 104.
Accordingly, in light of these difficulties and performance problems associated with transitioning between active and standby SIP hosts, there exists a need for improved methods, systems, and computer program products for managing a switchover event.